在 Molly 要開始講故事前，佳麗趕快問：”剛剛提到 User Story，真可以光靠『身為採購者，我需要找到符合規格性價比較高的商品，因為我是實用主義者』這樣的敘述就驅動開發團隊做出好產品？在公司強力要求，我已經很習慣利用 Use Case，可否在 Scrum 採用 Use Case”

Molly 雖然沒幹過所謂的系統分析師，但是參與過幾次採 Scrum 的專案，多少也有需求分析這樣的經驗。採Scrum的專案中每個開發成團隊的員都必須是多元，因為它的核心思維是團隊彼此合作解決問題，而非依照職務或是頭銜來分工。她看其他人也相當有興趣了解此問題，剛好吻合她期待大家多了解 Scrum，再聽故事。畢竟她的故事都是有深度的，她這樣定位自己。

"我有一個專案是 Product Owner，又兼開發團隊成員，再次強調我不推薦如此，這讓我吃了好多的苦。一開始大家也都說好要用 User Story 這工具，但是隨著專案進行，居然發展到後來有接近六十多個User Story，我們要跟客戶一起討論整個專案的需求，發現條列數十條的 Story，很難有全貌的視野。我們就採用 Use Case Diagram，不到一個小時，我們就把 五十多條的 User Story 轉換成一張Use Case Diagram。神奇的是當我們與客戶討論需求，他看著圖上的『用戶』這個Actor有連結到哪些 Use Case，馬上發現自己居然一直沒提出『身為用戶，我要知道我還有多少儲值餘額，以免讓我發生不足額，後續無法賺到獎勵』這樣的需求"

佳麗是Use Case專家，馬上發現一個小問題：”我猜你們雖然畫了Use Case Diagram，但沒有寫 Use Case Spec，通常像這麼顯著的需求，很容易在撰寫其他的 Use Case ，我猜原來可能會有『身為用戶，我要查詢累計獎勵額度』，如果有幫這個我虛構的Use Case寫Spec的過程中，很容易就會找到這個被遺漏掉的需求。”

“佳麗姐，你有接觸到那個專案喔？這麼神，的確是有那個你說是虛構的 Use Story。我如何從其他Use Case Spec 找到被忽略掉的需求？有技巧嗎？”

“通常分析師在寫使用案例，Use Case時會將所謂的 Happy Flow每個步驟寫得很順暢，只要多想一下，萬一發生意外時，系統該怎麼辦，通常會產生新的使用案例。這又是一個好大的話題，這樣好了，等專案進行時，有實際需求，我帶著大家寫寫 User Case Spec 好了，你們會發現還門檻還蠻低的。” 佳麗承諾。

Gavin 也馬上發現一個小問題：“我直覺 User Story 因為較無全面性的視圖，很難判斷每個 User Story 的規模大小，Sprint Plan會議裡要不要排進去某個 User Story，可能也是一個糾紛來源。但是如果是在UP，這個問題如何控制 Use Case 的規模方便排進 Iteration裡，是有個方法論。我知道佳麗也是很有經驗了，到時候也請佳麗跟大家分享。”

其他人對此領域的討論雖然也頗有興趣，但沒太多的深入，只能聽聽，無法太多交流，就當作學習。

會議隨著傍晚到來，準備要結束前，突然一通電話，RJ已經從歐洲趕回到公司了，要找 Gavin 聊聊。